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Dynamic Authorization Extensions to 
Remote Authentication Dial In User Service (RADIUS) 


Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


This document describes a currently deployed extension to the Remote 
Authentication Dial In User Service (RADIUS) protocol, allowing 
dynamic changes to a user session, as implemented by network access 
server products. This includes support for disconnecting users and 
changing authorizations applicable to a user session. 
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RADIUS protocol, defined in [RFC2865], does not support 
olicited messages sent from the RADIUS server to the Network 
ess Server (NAS). 


ever, there are many instances in which it is desirable for 
nges to be made to session characteristics, without requiring the 
to initiate the exchange. For example, it may be desirable for 


administrators to be able to terminate user session(s) in progress. 


Alt 


ernatively, if the user changes authorization level, this may 


require that authorization attributes be added/deleted from user 


ses 


To 
add 
be 
Dis 
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sion(s). 


overcome these limitations, several vendors have implemented 
itional RADIUS commands in order to enable unsolicited messages to 
sent to the NAS. These extended commands provide support for 
connect and Change-of-Authorization (CoA) packets. Disconnect 
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packets cause user session(s) to be terminated immediately, whereas 
CoA packets modify session authorization attributes such as data 
filters. 


1.1. Applicability 


This protocol is being recommended for publication as an 
Informational RFC rather than as a standards-track RFC because of 
problems that cannot be fixed without creating incompatibilities with 
deployed implementations. This includes security vulnerabilities, as 
well as semantic ambiguities resulting from the design of the 
Change-of-Authorization (CoA) commands. While fixes are recommended, 
they cannot be made mandatory since this would be incompatible with 
existing implementations. 


Existing implementations of this protocol do not support 
authorization checks, so that an ISP sharing a NAS with another ISP 
could disconnect or change authorizations for another ISP’s users. 

In order to remedy this problem, a "Reverse Path Forwarding" check is 
described; see Section 6.1 for details. 


Existing implementations utilize per-packet authentication and 
integrity protection algorithms with known weaknesses [MD5Attack]. 
To provide stronger per-packet authentication and integrity 
protection, the use of IPsec is recommended. See Section 6.2 for 
details. 


Existing implementations lack replay protection. In order to support 
replay detection, it is recommended that an Event-Timestamp Attribute 
be added to all packets in situations where IPsec replay protection 
is not employed. See Section 6.3 for details. 


The approach taken with CoA commands in existing implementations 
results in a semantic ambiguity. Existing implementations of the 
CoA-Request identify the affected session, as well as supply the 
authorization changes. Since RADIUS Attributes included within 
existing implementations of the CoA-Request can be used for session 
identification or authorization change, it may not be clear which 
function a given attribute is serving. 


The problem does not exist within the Diameter protocol [RFC3588], in 
which server-initiated authorization change is initiated using a 
Re-Auth-Request (RAR) command identifying the session via User-Name 
and Session-Id Attribute Value Pairs (AVPs) and containing a 
Re-Auth-Request-Type AVP with value "AUTHORIZE_ONLY". This results 
in initiation of a standard Request/Response sequence where 
authorization changes are supplied. As a result, in no command can 
Diameter AVPs have multiple potential meanings. 
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1.2. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


1.3. Terminology 
This document frequently uses the following terms: 


Dynamic Authorization Client (DAC) 
The entity originating Change of Authorization (CoA) Requests or 
Disconnect-Requests. While it is possible that the DAC is 
co-resident with a RADIUS authentication or accounting server, 
this need not necessarily be the case. 


Dynamic Authorization Server (DAS) 
The entity receiving CoA-Request or Disconnect-Request packets. 
The DAS may be a NAS or a RADIUS proxy. 


Network Access Server (NAS) 
The device providing access to the network. 


service 
The NAS provides a service to the user, such as IEEE 802 or 
Point-to-Point Protocol (PPP). 


session 
Each service provided by the NAS to a user constitutes a 
session, with the beginning of the session defined as the point 
where service is first provided and the end of the session 
defined as the point where service is ended. A user may have 
multiple sessions in parallel or series if the NAS supports 
that. 


silently discard 
This means the implementation discards the packet without 
further processing. The implementation SHOULD provide the 
capability of logging the error, including the contents of the 
silently discarded packet, and SHOULD record the event in a 
statistics counter. 


2. Overview 


This section describes the most commonly implemented features of 
Disconnect and Change-of-Authorization (CoA) packets. 
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2 


t; 


Disconnect Messages (DMs) 


A Disconnect-Request packet is sent by the Dynamic Authorization 
Client in order to terminate user session(s) on a NAS and discard all 
associated session context. The Disconnect-Request packet is sent to 
UDP port 3799, and identifies the NAS as well as the user session (s) 
to be terminated by inclusion of the identification attributes 
described in Section 3. 


Soo + +---------- + 
| | Disconnect-Request | | 
< [A EA A EAS E, 
| Nas | | DAC | 
| |. Disconnect-ACK/NAK | | 
| p >| | 
Soo + +---------- + 


The NAS responds to a Disconnect-Request packet sent by a Dynamic 
Authorization Client with a Disconnect-ACK if all associated session 
context is discarded and the user session(s) are no longer connected, 
or a Disconnect-NAK, if the NAS was unable to disconnect one or more 
sessions and discard all associated session context. A Disconnect- 
ACK MAY contain the Acct-Terminate-Cause (49) Attribute [RFC2866] 
with the value set to 6 for Admin-Reset. 


-2. Change-of-Authorization (CoA) Messages 


CoA-Request packets contain information for dynamically changing 
session authorizations. Typically, this is used to change data 
filters. The data filters can be of either the ingress or egress 
kind, and are sent in addition to the identification attributes as 
described in Section 3. The port used and packet format (described 
in Section 2.3) are the same as those for Disconnect-Request packets. 


The following attributes MAY be sent in a CoA-Request: 


Filter-ID (11) - Indicates the name of a data filter list 
to be applied for the session(s) that the 
identification attributes map to. 


NAS-Filter-Rule (92) - Provides a filter list to be applied for 
the session(s) that the identification 
attributes map to [RFC4849]. 
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| | CoA-Request | | 


NAS DAC 


The NAS responds to a CoA-Request sent by a Dynamic Authorization 
Client with a CoA-ACK if the NAS is able to successfully change the 
authorizations for the user session(s), or a CoA-NAK if the CoA- 
Request is unsuccessful. A NAS MUST respond to a CoA-Request 
including a Service-Type Attribute with an unsupported value with a 
CoA-NAK; an Error-Cause Attribute with value "Unsupported Service" 
SHOULD be included. 


2.3. Packet Format 


For either Disconnect-Request or CoA-Request packets UDP port 3799 is 
used as the destination port. For responses, the source and 
destination ports are reversed. Exactly one RADIUS packet is 
encapsulated in the UDP Data field. 


A summary of the data format is shown below. The fields are 
transmitted from left to right. 


The packet format consists of the following fields: Code, Identifier, 
Length, Authenticator, and Attributes in Type-Length-Value (TLV) 
format. All fields hold the same meaning as those described in 
RADIUS [RFC2865]. The Authenticator field MUST be calculated in the 
same way as is specified for an Accounting-Request in [RFC2866]. 


0 1 2 3 

OL. 2:3-4 5 6.71.890123456"708.09.01.2.3456 78.901 

-+-+-+-+-+-+-+-+-+- A A e O o o o + + +++ 
Code | Identifier | Length 

A A O A A A A e O + + +++ 


Authenticator | 


—— +—+ 


—+-+4+-4+-4+-+4+-4-4+-+-+4+-4+-4+-4+-4-4+-4+-+4+-4-4+-+4+-4-4+-4-+4+-4+-4+-4+-4-4+-+-4+-4-4+ 
Attributes 
—+-+-4+-4+-+-+4+-4+-+-+-4+-4+-4+- 


+—+ 
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Code 


The Code field is one octet, and identifies the type of RADIUS 
packet. Packets received with an invalid Code field MUST be 
Silently discarded. RADIUS codes (decimal) for this extension are 
assigned as follows: 


40 - Disconnect-Request [RFC3575] 
41 - Disconnect-ACK [RFC3575] 

42 - Disconnect-NAK [RFC3575] 

43 - CoA-Request [RFC3575] 

44 -— CoA-ACK [RFC3575] 

45 — CoA-NAK [RFC3575] 


Identifier 


Chiba, 


The Identifier field is one octet, and aids in matching requests 
and replies. A Dynamic Authorization Server implementing this 
specification MUST be capable of detecting a duplicate request if 
it has the same source IP address, source UDP port, and Identifier 
within a short span of time. 


The responsibility for retransmission of Disconnect-Request and 

CoA-Request packets lies with the Dynamic Authorization Client. 

If after sending these packets, the Dynamic Authorization Client 
does not receive a response, it will retransmit. 


The Identifier field MUST be changed whenever the content of the 
Attributes field changes, or whenever a valid reply has been 
received for a previous request. For retransmissions where the 
contents are identical, the Identifier MUST remain unchanged. 


If the Dynamic Authorization Client is retransmitting a 
Disconnect-Request or CoA-Request to the same Dynamic 
Authorization Server as before, and the attributes haven't 
changed, the same Request Authenticator, Identifier, and source 
port MUST be used. If any attributes have changed, a new 
Authenticator and Identifier MUST be used. 


If the Request to a primary Dynamic Authorization Server fails, a 
secondary Dynamic Authorization Server must be queried, if 
available; issues relating to failover algorithms are described in 
[RFC3539]. Since this represents a new request, a new Request 
Authenticator and Identifier MUST be used. However, where the 
Dynamic Authorization Client is sending directly to the NAS, 
failover typically does not make sense, since CoA-Request or 
Disconnect-Request packets need to be delivered to the NAS where 
the session resides. 
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Length 


The Length field is two octets. It indicates the length of the 
packet including the Code, Identifier, Length, Authenticator, and 
Attribute fields. Octets outside the range of the Length field 
MUST be treated as padding and ignored on reception. If the 
packet is shorter than the Length field indicates, it MUST be 
Silently discarded. The minimum length is 20 and maximum length 


is 4096. 

Authenticator 
The Authenticator field is sixteen (16) octets. The most 
significant octet is transmitted first. This value is used to 


authenticate packets between the Dynamic Authorization Client and 
the Dynamic Authorization Server. 


Request Authenticator 


In Request packets, the Authenticator value is a 16-octet MD5 
[RFC1321] checksum, called the Request Authenticator. The 
Request Authenticator is calculated the same way as for an 
Accounting-Request, specified in [RFC2866]. 


Note that the Request Authenticator of a CoA-Request or 
Disconnect-Request cannot be computed the same way as the 
Request Authenticator of a RADIUS Access-Request, because there 
is no User-Password Attribute in a CoA-Request or Disconnect- 
Request. 


Response Authenticator 


The Authenticator field in a Response packet (e.g., 
Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK) is called 
the Response Authenticator, and contains a one-way MD5 hash 
calculated over a stream of octets consisting of the Code, 
Identifier, Length, the Request Authenticator field from the 
packet being replied to, and the response attributes if any, 
followed by the shared secret. The resulting 16-octet MD5 hash 
value is stored in the Authenticator field of the Response 
packet. 


Administrative note: As noted in [RFC2865], Section 3, the secret 
(password shared between the Dynamic Authorization Client and the 
Dynamic Authorization Server) SHOULD be at least as large and 

unguessable as a well-chosen password. The Dynamic Authorization 
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Server MUST use the source IP address of the RADIUS UDP packet to 
decide which shared secret to use, so that requests can be 
proxied. 


Attributes 


Chiba, 


In CoA-Request and Disconnect-Request packets, all attributes MUST 
be treated as mandatory. If one or more authorization changes 
specified in a CoA-Request cannot be carried out, the NAS MUST 
send a CoA-NAK. A NAS MUST respond to a CoA-Request containing 
one or more unsupported attributes or Attribute values with a 
CoA-NAK; an Error-Cause Attribute with value 401 (Unsupported 
Attribute) or 407 (Invalid Attribute Value) MAY be included. A 
NAS MUST respond to a Disconnect-Request containing one or more 
unsupported attributes or Attribute values with a Disconnect-NAK; 
an Error-Cause Attribute with value 401 (Unsupported Attribute) or 
407 (Invalid Attribute Value) MAY be included. 


State changes resulting from a CoA-Request MUST be atomic: if the 
CoA-Request is successful for all matching sessions, the NAS MUST 
send a CoA-ACK in reply, and all requested authorization changes 
MUST be made. If the CoA-Request is unsuccessful for any matching 
sessions, the NAS MUST send a CoA-NAK in reply, and the requested 
authorization changes MUST NOT be made for any of the matching 
sessions. Similarly, a state change MUST NOT occur as a result of 
a Disconnect-Request that is unsuccessful with respect to any of 
the matching sessions; a NAS MUST send a Disconnect-NAK in reply 
if any of the matching sessions cannot be successfully terminated. 
A NAS that does not support dynamic authorization changes applying 
to multiple sessions MUST send a CoA-NAK or Disconnect-NAK in 
reply; an Error-Cause Attribute with value 508 (Multiple Session 
Selection Unsupported) SHOULD be included. 


Within this specification, attributes can be used for 
identification, authorization, or other purposes. RADIUS 
Attribute specifications created after publication of this 
document SHOULD state whether an attribute can be included in CoA 
or Disconnect messages, and if so, which messages it can be 
included in and whether it serves as an identification or 
authorization attribute. 


Even if a NAS implements an attribute for use with RADIUS 
authentication and accounting, it is possible that it will not 
support inclusion of that attribute within CoA-Request and 
Disconnect-Request packets, given the difference in attribute 
semantics. This is true even for attributes specified as 
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allowable within Access-Accept packets (such as those defined 
within [RFC2865], [RFC2868], [RFC2869], [RFC3162], [RFC3579], 
[RFC4372], [RFC4675], [RFC4818], and [RFC4849]). 


3. Attributes 


In Disconnect-Request and CoA-Request packets, certain attributes are 
used to uniquely identify the NAS as well as user session(s) on the 
NAS. The combination of NAS and session identification attributes 
included in a CoA-Request or Disconnect-Request packet MUST match at 
least one session in order for a Request to be successful; otherwise 
a Disconnect-NAK or CoA-NAK MUST be sent. If all NAS identification 
attributes match, and more than one session matches all of the 
session identification attributes, then a CoA-Request or Disconnect- 
Request MUST apply to all matching sessions. 


Identification attributes include NAS and session identification 


attributes, 


as described below. 


NAS identification attributes 


Attribute # Reference Description 

NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS. 
NAS-Identifier 32 [RFC2865] String identifying the NAS. 
NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS. 


Session identification attributes 


Attribute $ Reference Description 
User—Name 1 [RFC2865] The name of the user 
associated with one or 
more sessions. 
NAS-Port 5 [RFC2865] The port on which a 
session is terminated. 
Framed-IP-Address 8 [RFC2865] The IPv4 address associated 
with a session. 
Vendor-Specific 26 [RFC2865] One or more vendor-specific 
identification attributes. 
Called-Station-Id 30 [RFC2865] The link address to which 
a session is connected. 
Calling-Station-Id 31 [RFC2865] The link address from which 
one or more sessions are 
connected. 
Acct-Session-Id 44 [RFC2866] The identifier uniquely 
identifying a session 
on the NAS. 
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Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely 
identifying related sessions. 
NAS-Port-Id 87 [RFC2869] String identifying the port 
where a session is. 
Chargeable-User- 89 [RFC4372] The CUI associated with one 
Identity or more sessions. Needed 


where a privacy Network 
Access Identifier (NAI) is 
used, since in this case the 
User-Name (e.g., "anonymous") 
may not identify sessions 
belonging to a given user. 
Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier 
associated with a session, 
always sent with 
Framed-IPv6-Prefix. 
Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated 
with a session, always sent 
with Framed-Interface-Id. 


To address security concerns described in Section 6.1, either the 
User-Name or Chargeable-User-Identity attribute SHOULD be present in 
Disconnect-Request and CoA-Request packets. 


Where a Diameter client utilizes the same Session-Id for both 
authorization and accounting, inclusion of an Acct-Session-Id 
Attribute in a Disconnect-Request or CoA-Request can assist with 
Diameter/RADIUS translation, since Diameter RAR and ASR commands 
include a Session-Id AVP. An Acct-Session-Id Attribute SHOULD be 
included in Disconnect-Request and CoA-Request packets. 


A NAS implementing this specification SHOULD send an Acct-Session-Id 
or Acct-Multi-Session-Id Attribute within an Access-Request. Where 
an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not included 
within an Access-Request, the Dynamic Authorization Client will not 
know the Acct-Session-Id or Acct-Multi-Session-Id of the session it 
is attempting to target, unless it also has access to the accounting 
data for that session. 


Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not 
present in a CoA-Request or Disconnect-Request, it is possible that 
the User-Name or Chargeable-User-Identity attributes will not be 
sufficient to uniquely identify a single session (e.g., if the same 
user has multiple sessions on the NAS, or if the privacy NAI is 
used). In this case, if it is desired to identify a single session, 
session identification MAY be performed by using one or more of the 
Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called- 
Station-Id, Calling-Station-Id, NAS-Port, and NAS-Port-Id attributes. 
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To assist RADIUS proxies in routing Request packets to their 
destination, one or more of the NAS-IP-Address or NAS-IPv6-Address 
attributes SHOULD be present in CoA-Request and Disconnect-Request 
packets; the NAS-Identifier Attribute MAY be present. Impersonation 
issues with NAS Identification attributes are discussed in [RFC3579], 
Section 4.3.7. 


A Disconnect-Request MUST contain only NAS and session identification 
attributes. If other attributes are included in a Disconnect- 
Request, implementations MUST send a Disconnect-NAK; an Error-Cause 
Attribute with value "Unsupported Attribute" MAY be included. 


The DAC may require access to data from RADIUS authentication or 
accounting packets. It uses this data to compose compliant CoA- 
Request or Disconnect-Request packets. For example, as described in 
Section 3.3, a CoA-Request packet containing a Service-Type Attribute 
with a value of "Authorize Only" is required to contain a State 
Attribute. The NAS will subsequently transmit this attribute to the 
RADIUS server in an Access-Request. In order for the DAC to include 
a State Attribute that the RADIUS server will subsequently accept, 
some coordination between the two parties may be required. 


This coordination can be achieved in multiple ways. The DAC may be 
co-located with a RADIUS server, in which case it is presumed to have 
access to the necessary data. The RADIUS server may also store that 
information in a common database. The DAC can then be separated from 
the RADIUS server, so long as it has access to that common database. 


Where the DAC is not co-located with a RADIUS server, and does not 
have access to a common database, the DAC SHOULD send CoA-Request or 
Disconnect-Request packets to a RADIUS server acting as a proxy, 
rather than sending them directly to the NAS. 


A RADIUS server receiving a CoA-Request or Disconnect-Request packet 
from the DAC MAY then add or update attributes (such as adding NAS or 
session identification attributes or appending a State Attribute), 
prior to forwarding the packet. Having CoA/Disconnect-Requests 
forwarded by a RADIUS server can also enable upstream RADIUS proxies 
to perform a Reverse Path Forwarding (RPF) check (see Section 6.1). 


3.1. Proxy State 
If there are any Proxy-State attributes in a Disconnect-Request or 
CoA-Request received from the Dynamic Authorization Client, the 


Dynamic Authorization Server MUST include those Proxy-State 
attributes in its response to the Dynamic Authorization Client. 
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A forwarding proxy or NAS MUST NOT modify existing Proxy-State, 
State, or Class attributes present in the packet. The forwarding 
proxy or NAS MUST treat any Proxy-State attributes already in the 
packet as opaque data. Its operation MUST NOT depend on the content 
of Proxy-State attributes added by previous proxies. The forwarding 
proxy MUST NOT modify any other Proxy-State attributes that were in 
the packet; it may choose not to forward them, but it MUST NOT change 
their contents. If the forwarding proxy omits the Proxy-State 
attributes in the request, it MUST attach them to the response before 
sending it. 


When the proxy forwards a Disconnect-Request or CoA-Request, it MAY 
add a Proxy-State Attribute, but it MUST NOT add more than one. If a 
Proxy-State Attribute is added to a packet when forwarding the 
packet, the Proxy-State Attribute MUST be added after any existing 
Proxy-State attributes. The forwarding proxy MUST NOT change the 
order of any attributes of the same type, including Proxy-State. 
Other attributes can be placed before, after, or even between the 
Proxy-State attributes. 


When the proxy receives a response to a CoA-Request or Disconnect- 
Request, it MUST remove its own Proxy-State Attribute (the last 
Proxy-State in the packet) before forwarding the response. Since 
Disconnect and CoA responses are authenticated on the entire packet 
contents, the stripping of the Proxy-State Attribute invalidates the 
integrity check, so the proxy MUST recompute it. 


3.2. Authorize Only 


To simplify translation between RADIUS and Diameter, Dynamic 
Authorization Clients can include a Service-Type Attribute with value 
"Authorize Only" within a CoA-Request; see Section 4 for details on 
Diameter considerations. Support for a CoA-Request including a 
Service-Type Attribute with value "Authorize Only" is OPTIONAL on the 
NAS and Dynamic Authorization Client. A Service-Type Attribute MUST 
NOT be included within a Disconnect-Request. 


A NAS MUST respond to a CoA-Request including a Service-Type 
Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST 
NOT be sent. If the NAS does not support a Service-Type value of 
"Authorize Only", then it MUST respond with a CoA-NAK; an Error-Cause 
Attribute with a value of 405 (Unsupported Service) SHOULD be 
included. 


A CoA-Request containing a Service-Type Attribute with value 


"Authorize Only" MUST in addition contain only NAS or session 
identification attributes, as well as a State Attribute. If other 
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attributes are included in such a CoA-Request, a CoA-NAK MUST be 
sent; an Error-Cause Attribute with value 401 (Unsupported Attribute) 
SHOULD be included. 


If a CoA-Request packet including a Service-Type value of "Authorize 
Only" is successfully processed, the NAS MUST respond with a CoA-NAK 
containing a Service-Type Attribute with value "Authorize Only", and 
an Error-Cause Attribute with value 507 (Request Initiated). The NAS 
then MUST send an Access-Request to the RADIUS server including a 
Service-Type Attribute with value "Authorize Only", along with a 
State Attribute. This Access-Request SHOULD contain the NAS 
identification attributes from the CoA-Request, as well as the 
session identification attributes from the CoA-Request permitted in 
an Access-Request; it also MAY contain other attributes permitted in 
an Access-Request. 


As noted in [RFC2869], Section 5.19, a Message-Authenticator 
attribute SHOULD be included in an Access-Request that does not 
contain a User-Password, CHAP-Password, ARAP-Password, or EAP-Message 
Attribute. The RADIUS server then will respond to the Access-Request 
with an Access-Accept to (re-)authorize the session or an Access- 
Reject to refuse to (re-)authorize it. 


3.3. State 


The State Attribute is available to be sent by the Dynamic 
Authorization Client to the NAS in a CoA-Request packet and MUST be 
sent unmodified from the NAS to the Dynamic Authorization Client ina 
subsequent ACK or NAK packet. 


[RFC2865], Section 5.44 states: 


An Access-Request MUST contain either a User-Password or a 
CHAP-Password or State. An Access-Request MUST NOT contain both a 
User-Password and a CHAP-Password. If future extensions allow 
other kinds of authentication information to be conveyed, the 
attribute for that can be used in an Access-Request instead of 
User-Password or CHAP-Password. 


In order to satisfy the requirements of [RFC2865], Section 5.44, an 
Access-Request with Service-Type Attribute with value "Authorize 
Only" MUST contain a State Attribute. 


In order to provide a State Attribute to the NAS, a Dynamic 
Authorization Client sending a CoA-Request with a Service-Type 
Attribute with a value of "Authorize Only" MUST include a State 
Attribute, and the NAS MUST send the State Attribute unmodified to 
the RADIUS server in the resulting Access-Request, if any. A NAS 


Chiba, et al. Informational [Page 14] 


RFC 5176 Dynamic Authorization Extensions to RADIUS January 2008 


receiving a CoA-Request containing a Service-Type Attribute with a 

value of "Authorize Only" but lacking a State Attribute MUST send a 
CoA-NAK and SHOULD include an Error-Cause Attribute with a value of 
402 (Missing Attribute). 


The State Attribute is also available to be sent by the Dynamic 
Authorization Client to the NAS in a CoA-Request that also includes a 
Termination-Action Attribute with the value of RADIUS-Request. If 
the NAS performs the Termination-Action by sending a new Access- 
Request upon termination of the current session, it MUST include the 
State Attribute unchanged in that Access-Request. In either usage, 
the Dynamic Authorization Server MUST NOT interpret the Attribute 
locally. A CoA-Request packet MUST have only zero or one State 
Attribute. Usage of the State Attribute is implementation dependent. 


3.4. Message-Authenticator 


The Message-Authenticator Attribute MAY be used to authenticate and 
integrity-protect CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request, 
Disconnect-ACK, and Disconnect-NAK packets in order to prevent 
spoofing. 


A Dynamic Authorization Server receiving a CoA-Request or 
Disconnect-Request with a Message-Authenticator Attribute present 
MUST calculate the correct value of the Message-Authenticator and 
silently discard the packet if it does not match the value sent. A 
Dynamic Authorization Client receiving a CoA/Disconnect-ACK or 
CoA/Disconnect-NAK with a Message-Authenticator Attribute present 
MUST calculate the correct value of the Message-Authenticator and 
silently discard the packet if it does not match the value sent. 


When a Message-Authenticator Attribute is included within a CoA- 
Request or Disconnect-Request, it is calculated as follows: 


Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, 
Request Authenticator, Attributes) 


When the HMAC-MD5 message integrity check is calculated the 
Request Authenticator field and Message-Authenticator Attribute 
MUST each be considered to be sixteen octets of zero. The 
Message-Authenticator Attribute is calculated and inserted in the 
packet before the Request Authenticator is calculated. 
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When a Message-Authenticator Attribute is included within a CoA- 
ACK, CoA-NAK, Disconnect-ACK, or Disconnect-NAK, it is calculated 
as follows: 


Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, 
Request Authenticator, Attributes) 


When the HMAC-MD5 message integrity check is calculated, the 
Message-Authenticator Attribute MUST be considered to be sixteen 
octets of zero. The Request Authenticator is taken from the 
corresponding CoA/Disconnect-Request. The Message-Authenticator 
is calculated and inserted in the packet before the Response 
Authenticator is calculated. 


3.5. Error-Cause 
Description 


It is possible that a Dynamic Authorization Server cannot honor 
Disconnect-Request or CoA-Request packets for some reason. The 
Error-Cause Attribute provides more detail on the cause of the 

problem. It MAY be included within CoA-NAK and Disconnect-NAK 

packets. 


A summary of the Error-Cause Attribute format is shown below. The 
fields are transmitted from left to right. 


0 1 2 3 
01234567890123456789012345678<901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value (cont) 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 
101 for Error-Cause 
Length 
6 
Value 
The Value field is four octets, containing an integer specifying 


the cause of the error. Values 0-199 and 300-399 are reserved. 
Values 200-299 represent successful completion, so that these 
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values may only be sent within CoA-ACK or Disconnect-ACK packets 
and MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet. 
Values 400-499 represent fatal errors committed by the Dynamic 
Authorization Client, so that they MAY be sent within CoA-NAK or 
Disconnect-NAK packets, and MUST NOT be sent within CoA-ACK or 
Disconnect-ACK packets. Values 500-599 represent fatal errors 
occurring on a Dynamic Authorization Server, so that they MAY be 
sent within CoA-NAK and Disconnect-NAK packets, and MUST NOT be 
sent within CoA-ACK or Disconnect-ACK packets. Error-Cause values 
SHOULD be logged by the Dynamic Authorization Client. Error-Code 
values (expressed in decimal) include: 


# Value 
201 Residual Session Context Removed 
202 Invalid EAP Packet (Ignored) 
401 Unsupported Attribute 
402 Missing Attribute 
403 NAS Identification Mismatch 
404 Invalid Request 
405 Unsupported Service 
406 Unsupported Extension 
407 Invalid Attribute Value 
501 Administratively Prohibited 
502 Request Not Routable (Proxy) 
503 Session Context Not Found 
504 Session Context Not Removable 
505 Other Proxy Processing Error 
506 Resources Unavailable 
507 Request Initiated 
508 Multiple Session Selection Unsupported 


"Residual Session Context Removed" is sent in response to a 
Disconnect-Request if one or more user sessions are no longer 
active, but residual session context was found and successfully 
removed. This value is only sent within a Disconnect-ACK and MUST 
NOT be sent within a CoA-ACK, Disconnect-NAK, or CoA-NAK. 


"Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT 
be sent by implementations of this specification. 


"Unsupported Attribute" is a fatal error sent if a Request 
contains an attribute (such as a Vendor-Specific or EAP-Message 
Attribute) that is not supported. 


"Missing Attribute" is a fatal error sent if critical attributes 


(such as NAS or session identification attributes) are missing 
from a Request. 
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"NAS Identification Mismatch" is a fatal error sent if one or more 
NAS identification attributes (see Section 3) do not match the 
identity of the NAS receiving the Request. 


"Invalid Request" is a fatal error sent if some other aspect of 
the Request is invalid, such as if one or more attributes (such as 
EAP-Message Attribute(s)) are not formatted properly. 


"Unsupported Service" is a fatal error sent if a Service-Type 
Attribute included with the Request is sent with an invalid or 
unsupported value. This error cannot be sent in response to a 
Disconnect-Request. 


"Unsupported Extension" is a fatal error sent due to lack of 
support for an extension such as Disconnect and/or CoA packets. 
This will typically be sent by a proxy receiving an ICMP port 
unreachable message after attempting to forward a CoA-Request or 
Disconnect-Request to the NAS. 


"Invalid Attribute Value" is a fatal error sent if a CoA-Request 
or Disconnect-Request contains an attribute with an unsupported 
value. 


"Administratively Prohibited" is a fatal error sent if the NAS is 
configured to prohibit honoring of CoA-Request or Disconnect- 
Request packets for the specified session. 


"Request Not Routable" is a fatal error that MAY be sent by a 
proxy and MUST NOT be sent by a NAS. It indicates that the proxy 
was unable to determine how to route a CoA-Request or Disconnect- 
Request to the NAS. For example, this can occur if the required 
entries are not present in the proxy's realm routing table. 


"Session Context Not Found" is a fatal error sent if the session 
context identified in the CoA-Request or Disconnect-Request does 
not exist on the NAS. 


"Session Context Not Removable" is a fatal error sent in response 
to a Disconnect-Request if the NAS was able to locate the session 
context, but could not remove it for some reason. It MUST NOT be 
sent within a CoA-ACK, CoA-NAK, or Disconnect-ACK, only within a 
Disconnect-NAK. 


"Other Proxy Processing Error" is a fatal error sent in response 


to a CoA or Disconnect-Request that could not be processed by a 
proxy, for reasons other than routing. 
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"Resources Unavailable" is a fatal error sent when a CoA or 
Disconnect-Request could not be honored due to lack of available 
NAS resources (memory, non-volatile storage, etc.). 


"Request Initiated" is a fatal error sent by a NAS in response to 
a CoA-Request including a Service-Type Attribute with a value of 
"Authorize Only". It indicates that the CoA-Request has not been 
honored, but that the NAS is sending one or more RADIUS Access- 
Requests including a Service-Type Attribute with value "Authorize 
Only" to the RADIUS server. 


"Multiple Session Selection Unsupported" is a fatal error sent by 
a NAS in response to a CoA-Request or Disconnect-Request whose 
session identification attributes match multiple sessions, where 
the NAS does not support Requests applying to multiple sessions. 
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3.6. Table of Attributes 


The following table provides a guide to which attributes may be found 
in which packets, and in what quantity. 


Change-of-Authorization Messages 


Request ACK NAK # Attribute 

0-1 0 0 1 User-Name (Note 1) 

0-1 0 0 4 NAS-IP-Address (Note 1) 

0-1 0 0 5 NAS-Port (Note 1) 

0-1 0 0-1 6 Service-Type 

0-1 0 0 7 Framed-Protocol (Note 3) 
0-1 0 0 8 Framed-IP-Address (Notes 1, 6) 
0-1 0 0 9 Framed-IP-Netmask (Note 3) 
0-1 0 0 10 Framed-Routing (Note 3) 

0+ 0 0 11 Filter-ID (Note 3) 

0-1 0 0 12 Framed-MTU (Note 3) 

0+ 0 0 13 Framed-Compression (Note 3) 
0+ 0 0 14 Login-IP-Host (Note 3) 

0-1 0 0 15 Login-Service (Note 3) 

0-1 0 0 16 Login-TCP-Port (Note 3) 

0+ 0 0 18 Reply-Message (Note 2) 

0-1 0 0 19 Callback-Number (Note 3) 
0-1 0 0 20 Callback-Id (Note 3) 

O+ 0 0 22 Framed-Route (Note 3) 

0-1 0 0 23 Framed-IPX-Network (Note 3) 
0-1 0-1 0-1 24 State 

0+ 0 0 25 Class (Note 3) 

0+ 0 0 26 Vendor-Specific (Note 7) 
0-1 0 0 ZT Session-Timeout (Note 3) 
0-1 0 0 28 Idle-Timeout (Note 3) 

0-1 0 0 29 Termination-Action (Note 3) 
Request ACK NAK $ Attribute 
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Request ACK NAK # Attribute 

0-1 0 0 30 Called-Station-Id (Note 1) 

0-1 0 0 31 Calling-Station-Id (Note 1) 

0-1 0 0 32 NAS-Identifier (Note 1) 

0+ 0+ 0+ 33 Proxy-State 

0-1 0 0 34 Login-LAT-Service (Note 3) 

0-1 0 0 35 Login-LAT-Node (Note 3) 

0-1 0 0 36 Login-LAT-Group (Note 3) 

0-1 0 0 Sy Framed-AppleTalk-Link (Note 3) 
0+ 0 0 38 Framed-AppleTalk-Network (Note 3) 
0-1 0 0 39 Framed-AppleTalk-Zone (Note 3) 
0-1 0 0 44 Acct-Session-Id (Note 1) 

0-1 0 0 50 Acct-Multi-Session-Id (Note 1) 
0-1 0-1 0-1, +35 Event-Timestamp 

0+ 0 0 56 Egress-VLANID (Note 3) 

0-1 0 0 57 Ingress-Filters (Note 3) 

0+ 0 0 58 Egress-VLAN-Name (Note 3) 

0-1 0 0 59 User-Priority-Table (Note 3) 
0-1 0 0 61 NAS-Port-Type (Note 3) 

0-1 0 0 62 Port-Limit (Note 3) 

0-1 0 0 63 Login-LAT-Port (Note 3) 

0+ 0 0 64 Tunnel-Type (Note 5) 

0+ 0 0 65 Tunnel-Medium-Type (Note 5) 

0+ 0 0 66 Tunnel-Client-Endpoint (Note 5) 
0+ 0 0 67 Tunnel-Server-Endpoint (Note 5) 
0+ 0 0 69 Tunnel-Password (Note 5) 

0-1 0 0 71 ARAP-Features (Note 3) 

0-1 0 0 72 ARAP-Zone-Access (Note 3) 

0+ 0 0 78 Configuration-Token (Note 3) 

0+ 0-1 0 79 EAP-Message (Note 2) 

0-1 0-1 0-1 80 Message-Authenticator 

0+ 0 0 81 Tunnel-Private-Group-ID (Note 5) 
0+ 0 0 82 Tunnel-Assignment-ID (Note 5) 
0+ 0 0 83 Tunnel-Preference (Note 5) 

0-1 0 0 85 Acct-Interim-Interval (Note 3) 
0-1 0 0 87 NAS-Port-Id (Note 1) 

0-1 0 0 88 Framed-Pool (Note 3) 

0-1 0 0 89 Chargeable-User-Identity (Note 1) 
0+ 0 0 90 Tunnel-Client-Auth-ID (Note 5) 
0+ 0 0 91 Tunnel-Server-Auth-ID (Note 5) 
0-1 0 0 92 NAS-Filter-Rule (Note 3) 

0 0 0 94 Originating-Line-Info 

0-1 0 0 95 NAS-IPv6-Address (Note 1) 

0-1 0 0 96 Framed-Interface-Id (Notes 1, 6) 
O+ 0 0 97 Framed-IPv6-Prefix (Notes 1, 6) 
0+ 0 0 98 Login-IPv6-Host (Note 3) 

0+ 0 0 99 Framed-IPv6-Route (Note 3) 
Request ACK NAK # Attribute 
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Request ACK NAK + Attribute 

0-1 0 0 100 Framed-IPv6-Pool (Note 3) 

0 0 0+ 101 Error-Cause 

0+ 0 0 123 Delegated-IPv6-Prefix (Note 3) 
Request ACK NAK $ Attribute 


Disconnect Messages 


Request ACK NAK $ Attribute 

0-1 0 0 1 User-Name (Note 1) 

0-1 0 0 4 NAS-IP-Address (Note 1) 

0=1 0 0 5 NAS-Port (Note 1) 

0 0 0 6 Service-Type 

0 0 0 8 Framed-IP-Address (Note 1) 
0+ 0 0 18 Reply-Message (Note 2) 

0 0 0 24 State 

0+ 0 0 25 Class (Note 4) 

O+ 0 0 26 Vendor-Specific (Note 7) 

0-1 0 0 30 Called-Station-Id (Note 1) 
0-1 0 0 3i Calling-Station-Id (Note 1) 
0-1 0 0) 32 NAS-Identifier (Note 1) 

0+ 0+ 0+ 33 Proxy-State 

0=1 0 0 44 Acct-Session-Id (Note 1) 

0-1 0-1 0 49 Acct-Terminate-Cause 

0-1 0 0 50 Acct-Multi-Session-Id (Note 1) 
0-1 0-1 0-1 55 Event-Timestamp 

0 0 0 61 NAS-Port-Type 

0+ 0-1 0 79 EAP-Message (Note 2) 

0-1 0-1 0-1 80 Message-Authenticator 

0-1 0 0 87 NAS-Port-Id (Note 1) 

0-1 0 0 89 Chargeable-User-Identity (Note 1) 
0-1 0 0 95 NAS-IPv6-Address (Note 1) 

0 0 0 96 Framed-Interface-Id (Note 1) 
0 0 0 97 Framed-IPv6-Prefix (Note 1) 
0 0 O+ 101 Error-Cause 

Request ACK NAK $ Attribute 


The following defines the meaning of the above table entries: 


0 This attribute MUST NOT be present in packet. 

0+ Zero or more instances of this attribute MAY be present in 
packet. 

0-1 Zero or one instance of this attribute MAY be present in packet. 

1 Exactly one instance of this attribute MUST be present in 
packet. 
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(Note 1) Where NAS or session identification attributes are included 
in Disconnect-Regquest or CoA-Request packets, they are used for 
identification purposes only. These attributes MUST NOT be used for 
purposes other than identification (e.g., within CoA-Request packets 
to request authorization changes). 


(Note 2) The Reply-Message Attribute is used to present a displayable 
message to the user. The message is only displayed as a result of a 
successful Disconnect-Request or CoA-Request (where a Disconnect-ACK 
or CoA-ACK is subsequently sent). Where Extension Authentication 
Protocol (EAP) is used for authentication, an EAP- 
Message/Notification-Request Attribute is sent instead, and 
Disconnect-ACK or CoA-ACK packets contain an EAP- 
Message/Notification-Response Attribute. 


(Note 3) When included within a CoA-Request, these attributes 
represent an authorization change request. When one of these 
attributes is omitted from a CoA-Request, the NAS assumes that the 
attribute value is to remain unchanged. Attributes included ina 
CoA-Request replace all existing values of the same attribute(s). 


(Note 4) When included within a successful Disconnect-Request (where 
a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be 
sent unmodified by the NAS to the RADIUS accounting server in the 
Accounting Stop packet. If the Disconnect-Request is unsuccessful, 
then the Class Attribute is not processed. 


(Note 5) When included within a CoA-Request, these attributes 
represent an authorization change request. Where tunnel attributes 
are included within a successful CoA-Request, all existing tunnel 
attributes are removed and replaced by the new attribute(s). 


(Note 6) Since the Framed-IP-Address, Framed-IPv6-Prefix, and 
Framed-Interface-Id attributes are used for session identification, 
renumbering cannot be accomplished by including values of these 
attributes within a CoA-Request. Instead, a CoA-Request including a 
Service-Type Attribute with a value of "Authorize Only" is sent; new 
values can be supplied in an Access-Accept sent in response to the 
ensuing Access-Request. Note that renumbering will not be possible 
in all situations. For example, in order to change an IP address, 
IPCP or IPv6CP re-negotiation could be required, which is not 
supported by all PPP implementations. 


(Note 7) Within Disconnect-Request packets, Vendor-Specific 
Attributes (VSAs) MAY be used for session identification. Within 
CoA-Request packets, VSAs MAY be used for either session 
identification or authorization change. However, the same Attribute 
MUST NOT be used for both purposes simultaneously. 
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4. 


Diameter Considerations 


Due to differences in handling change-of-authorization requests in 
RADIUS and Diameter, it may be difficult or impossible for a 
Diameter/RADIUS gateway to successfully translate a Diameter 
Re-Auth-Request (RAR) to a CoA-Request and vice versa. For example, 
since a CoA-Request only initiates an authorization change but does 
not initiate re-authentication, a RAR command containing a 
Re-Auth-Request-Type AVP with value "AUTHORIZE_AUTHENTICATE" cannot 
be directly translated to a CoA-Request. A Diameter/RADIUS gateway 
receiving a CoA-Request containing authorization changes will need to 
translate this into two Diameter exchanges. First, the 
Diameter/RADIUS gateway will issue a RAR command including a 
Session-Id AVP and a Re-Auth-Request-Type AVP with value "AUTHORIZE 
ONLY". Then the Diameter/RADIUS gateway will respond to the ensuing 
access request with a response including the authorization attributes 
gleaned from the CoA-Request. To enable translation, the CoA-Request 
SHOULD include a Acct-Session-Id Attribute. If the Diameter client 
uses the same Session-Id for both authorization and accounting, then 
the Diameter/RADIUS gateway can copy the contents of the Acct- 
Session-Id Attribute into the Session-Id AVP; otherwise, it will 
need to map the Acct-Session-Id value to an equivalent Session-Id for 
use within a RAR command. 


Where an Acct-Session-Id Attribute is not present in a CoA-Request or 
Disconnect-Request, a Diameter/RADIUS gateway will either need to 
determine the appropriate Acct-Session-Id or, if it cannot do so, it 
can send a CoA-NAK or Disconnect-NAK in reply, possibly including an 
Error-Cause Attribute with a value of 508 (Multiple Session Selection 
Unsupported). 


To simplify translation between RADIUS and Diameter, Dynamic 
Authorization Clients can include a Service-Type Attribute with value 
"Authorize Only" within a CoA-Request, as described in Section 3.2. 

A Diameter/RADIUS gateway receiving a CoA-Request containing a 
Service-Type Attribute with a value "Authorize Only" translates this 
to a RAR with Re-Auth-Request-Type AVP with value "AUTHORIZE ONLY". 
The received RAA is then translated to a CoA-NAK with a Service-Type 
Attribute with value "Authorize Only". If the Result-Code AVP in the 
RAA has a value in the success category, then an Error-Cause 
Attribute with value "Request Initiated" is included in the CoA-NAK. 
If the Result-Code AVP in the RAA has a value indicating a Protocol 
Error or a Transient or Permanent Failure, then an alternate Error- 
Cause Attribute is returned as suggested below. 


Within Diameter, a server can request that a session be aborted by 
sending an Abort-Session-Request (ASR), identifying the session to be 
terminated using Session-ID and User-Name AVPs. The ASR command is 
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translated to a Disconnect-Request containing Acct-Session-Id and 


User-Name attributes. 


If the Diameter client utilizes the same 
Session-Id in both authorization and accounting, 


then the value of 


the Session-ID AVP may be placed in the Acct-Session-Id Attribute; 
otherwise the value of the Session-ID AVP will need to be mapped to 


an appropriate Acct-Session-Id Attribute. 
Disconnect-Request to an ASR, 


present. 


To enable translation of a 


an Acct-Session-Id Attribute SHOULD be 


If the Diameter client utilizes the same Session-Id in both 


authorization and accounting, 


then the value of the Acct-Session-Id 


Attribute may be placed into the Session-ID AVP within the ASR; 
otherwise the value of the Acct-Session-Id Attribute will need to be 
mapped to an appropriate Session-ID AVP. 


An Abort-Session-Answer 


(ASA) 


command is sent in response to an ASR 


in order to indicate the disposition of the request. A 
Diameter/RADIUS gateway receiving a Disconnect-ACK translates this to 


an ASA command with a Result-Code AVP of 


"DIAMETER_SUCCESS". A 


Disconnect-NAK received from the NAS is translated to an ASA command 
with a Result-Code AVP that depends on the value of the Error-Cause 


Attribute. 


Suggested translations between Error-Cause Attribute 


values and Result-Code AVP values are included below: 


# 
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Error-Cause Attribute Value 
Residual Session Context 
Removed 

Invalid EAP Packet 
(Ignored) 

Unsupported Attribute 
Missing Attribute 

NAS Identification 
Mismatch 

Invalid Request 
Unsupported Service 
Unsupported Extension 
Invalid Attribute Value 
Administratively 
Prohibited 

Request Not Routable (Proxy) 
Session Context Not Found 
Session Context Not 
Removable 

Other Proxy Processing 
Error 

Resources Unavailable 
Request Initiated 


Informational 


Result-Code AVP 


DIAMETER_SUCCESS 
DIAMETER_LIMITED_SUCCESS 


DIAMETER_AVP_UNSUPPORTED 
DIAMETER_MISSING_AVP 
DIAMETER_REALM NOT_SERVED 


DIAMETER_UNABLE_TO_COMPLY 
DIAMETER_COMMAND_UNSUPPORTED 
DIAMETER_APPLICATION_UNSUPPORTED 
DIAMETER_INVALID_AVP_ VALUE 
DIAMETER_AUTHORIZATION_REJECTED 


DIAMETER_UNABLE_TO_DELIVER 
DIAMETER_UNKNOWN_SESSION_ID 
DIAMETER_AUTHORIZATION_REJECTED 


DIAMETER_UNABLE_TO_COMPLY 


DIAMETER_RESOURCES_EXCEEDED 
DIAMETER_SUCCESS 
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Since both the ASR/ASA and Disconnect-Request/Disconnect- 
NAK/Disconnect-ACK exchanges involve just a request and response, 
inclusion of an "Authorize Only" Service-Type within a Disconnect- 
Request is not needed to assist in Diameter/RADIUS translation, and 
may make translation more difficult. As a result, as noted in 
Section 3.2, the Service-Type Attribute MUST NOT be used within a 
Disconnect-Request. 


5. IANA Considerations 


This document uses the RADIUS [RFC2865] namespace; see 
<http://www.iana.org/assignments/radius-types>. In addition to the 
allocations already made in [RFC3575] and [RFC3576], this 
specification allocates additional values of the Error-Cause 
Attribute (101): 


407 Invalid Attribute Value 
508 Multiple Session Selection Unsupported 


6. Security Considerations 
6.1. Authorization Issues 


Where a NAS is shared by multiple providers, it is undesirable for 
one provider to be able to send Disconnect-Requests or CoA-Requests 
affecting the sessions of another provider. 


A Dynamic Authorization Server MUST silently discard Disconnect- 
Request or CoA-Request packets from untrusted sources. In situations 
where the Dynamic Authorization Client is co-resident with a RADIUS 
authentication or accounting server, a proxy MAY perform a "reverse 
path forwarding" (RPF) check to verify that a Disconnect-Request or 
CoA-Request originates from an authorized Dynamic Authorization 
Client. In addition, it SHOULD be possible to explicitly authorize 
additional sources of Disconnect-—Request or CoA-Request packets 
relating to certain classes of sessions. For example, a particular 
source can be explicitly authorized to send CoA-Request packets 
relating to users within a set of realms. 


To perform the RPF check, the Dynamic Authorization Server uses the 
session identification attributes included in Disconnect-Request or 
CoA-Request packets, in order to determine the RADIUS server(s) to 
which an equivalent Access-Request could be routed. If the source 
address of the Disconnect-Request or CoA-Request is within this set, 
then the CoA-Request or Disconnect-Request is forwarded; otherwise it 
MUST be silently discarded. 
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Typically, the Dynamic Authorization Server will extract the realm 
from the Network Access Identifier [RFC4282] included within the 
User-Name or Chargeable-User-Identity Attribute, and determine the 
corresponding RADIUS servers in the realm routing tables. If the 
Dynamic Authorization Server maintains long-term session state, it 
MAY perform the authorization check based on the session 
identification attributes in the CoA-Request. The session 
identification attributes can be used to tie a session to a 
particular proxy or set of proxies, as with the NAI realm. 


Where no proxy is present, the RPF check can only be performed by the 
NAS if it maintains its own a realm routing table. If the NAS does 
not maintain a realm routing table (e.g., it selects forwarding 
proxies based on primary/secondary configuration and/or liveness 
checks), then an RPF check cannot be performed. 


Since authorization to send a Disconnect-Request or CoA-Request is 
determined based on the source address and the corresponding shared 
secret, the Dynamic Authorization Server SHOULD configure a different 
shared secret for each Dynamic Authorization Client. 


6.2. IPsec Usage Guidelines 


In addition to security vulnerabilities unique to Disconnect or CoA 
packets, the protocol exchanges described in this document are 
susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is 
RECOMMENDED that IPsec be employed to afford better security, 
utilizing the profile described in [RFC3579], Section 4.2. 


For Dynamic Authorization Servers implementing this specification, 
the IPsec policy would be "Require IPsec, from any to me, destination 
port UDP 3799". This causes the Dynamic Authorization Server to 
require use of IPsec. If some Dynamic Authorization Clients do not 
support IPsec, then a more granular policy will be required: "Require 
IPsec, from IPsec-Capable-DAC to me". 


For Dynamic Authorization Clients implementing this specification, 
the IPsec policy would be "Initiate IPsec, from me to any, 
destination port UDP 3799". This causes the Dynamic Authorization 
Client to initiate IPsec when sending Dynamic Authorization traffic 
to any Dynamic Authorization Server. If some Dynamic Authorization 
Servers contacted by the Dynamic Authorization Client do not support 
IPsec, then a more granular policy will be required, such as 
"Initiate IPsec, from me to IPsec-Capable-DAS, destination port UDP 
3199"; 
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6.3. Replay Protection 


Where IPsec replay protection is not used, an Event-Timestamp (55) 
[RFC2869] Attribute SHOULD be included within CoA-Request and 
Disconnect-Request packets, and MAY be included within CoA-ACK, CoA- 
NAK, Disconnect-ACK, and Disconnect-NAK packets. 


When the Event-Timestamp Attribute is present, both the Dynamic 
Authorization Server and the Dynamic Authorization Client MUST check 
that the Event-Timestamp Attribute is current within an acceptable 
time window. If the Event-Timestamp Attribute is not current, then 
the packet MUST be silently discarded. This implies the need for 
loose time synchronization within the network, which can be achieved 
by a variety of means, including Simple Network Time Protocol (SNTP), 
as described in [RFC4330]. Implementations SHOULD be configurable to 
discard CoA-Request or Disconnect-Request packets not containing an 
Event-Timestamp Attribute. 


If the Event-Timestamp Attribute is included, it represents the time 
at which the original packet was sent, and therefore it SHOULD NOT be 
updated when the packet is retransmitted. If the Event-Timestamp 
Attribute is not updated, this implies that the Identifier is not 
changed in retransmitted packets. As a result, the ability to detect 
replay within the time window is dependent on support for duplicate 
detection within that same window. As noted in Section 2.3, 
duplicate detection is REQUIRED for Dynamic Authorization Servers 
implementing this specification. 


The time window used for duplicate detection MUST be the same as the 
window used to detect a stale Event-Timestamp Attribute. Since the 
RADIUS Identifier cannot be repeated within the selected time window, 
no more than 256 Requests can be accepted within the time window. As 
a result, the chosen time window will depend on the expected maximum 
volume of CoA/Disconnect-Requests, so that unnecessary discards can 
be avoided. A default time window of 300 seconds should be adequate 
in many circumstances. 


7. Example Traces 
Disconnect Request with User-Name: 
0: XXXX XXXX XXXX XXXX XXXX 2801 001c 1b23 Bata A ot 


16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 DLO CeO ye Uso a 
32: 6d63 6869 6261 
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Disconnect Request with Acct-Session-ID: 


0: XXXX 
16: 8e53 
32: 3930 


XXXX XXXX XXXX Xxxx 2801 00le ad0d ¿Dot PAS AA 
55b6 bd02 a0cb ace6 4e38 77bd 2c0a SU ad N8w.,. 
3233 3435 3637 90234567 


Disconnect Request with Framed-IP-Address: 


QO: XXXX XXXX XXXX XXXX XXXX 2801 0O0la Obda ¿Bites A CA 
16: 33fe 765b O5f0 fd9c c32a 2f6b 5182 0806 ERAS */kQ... 
32: 0a00 0203 
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Appendix A. Changes from RFC 3576 


This Appendix lists the major changes between [RFC3576] and this 
document. Minor changes, including style, grammar, spelling, and 
editorial changes, are not mentioned here. 


o The term "Dynamic Authorization Client" is used instead of RADIUS 
server where it applies to the originator of CoA-Request and 


Disconnect-Request packets. The term "Dynamic Authorization Server" 
is used instead of NAS where it applies to the receiver of CoA- 
Request and Disconnect-Request packets. Definitions of these terms 


have been added (Section 1.3). 


o Added requirement for duplicate detection on the Dynamic 
Authorization Server (Section 2.3). 


o Clarified expected behavior when session identification attributes 
match more than one session (Sections 2.3, 3, 3.5, 4). 


o Added Chargeable-User-Identity as a session identification 
attribute. Removed NAS-Port-Type as a session identification 
attribute (Section 3). 


o Added recommendation that an Acct-Session-Id or Acct-Multi- 
Session-Id Attribute be included in an Access-Request (Section 3). 


o Added discussion of scenarios in which the "Dynamic Authorization 
Client" and RADIUS server are not co-located (Section 3). 


o Added details relating to handling of the Proxy-State Attribute 
(Section 3.1). 


o Added clarification that support for a Service-Type Attribute with 
value "Authorize Only" is optional on both the NAS and Dynamic 


Authorization Client (Section 3.2). Use of the Service-Type 
Attribute within a Disconnect-Request is prohibited (Sections 3.2, 
3.6). 


o Added requirement for inclusion of the State Attribute in CoA- 
Request packets including a Service-Type Attribute with a value of 
"Authorize Only" (Section 3.3). 


o Added clarification on the calculation of the Message- 
Authenticator Attribute (Section 3.4). 


o Additional Error-Cause Attribute values are allocated for Invalid 


Attribute Value (407) and Multiple Session Selection 
Identification (508) (Sections 3.5, 4). 
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Chiba, 


Updated the CoA-Request Attribute Table to include Filter-Rule, 
Delegated-IPv6-Prefix, Egress-VLANID, Ingress-Filters, Egress- 
VLAN-Name, and User-Priority attributes (Section 3.6). 


Added the Chargeable-User-Identity Attribute to both the CoA- 
Request and Disconnect-Request Attribute table (Section 3.6). 


Use of Vendor-Specific Attributes (VSAs) for session 
identification and authorization change has been clarified 
(Section 3.6). 


Added Note 6 on the use of the CoA-Request for renumbering, and 
Note 7 on the use of Vendor-Specific attributes (Section 3.6). 


Added Diameter Considerations (Section 4). 


Event-Timestamp Attribute should not be recalculated on 
retransmission. The implications for replay and duplicate 
detection are discussed (Section 6.3). 


Operation of the Reverse Path Forwarding (RPF) check has been 
clarified. Use of the RPF check is optional rather than 
recommended by default (Section 6.1). 


Text on impersonation (included in [RFC3579], Section 4.3.7) and 


IPsec operation (included in [RFC3579], Section 4.2) has been 
removed, and is now referenced. 
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